Multicast and broadcast are techniques for transferring data from one source to multiple destinations. In a conventional mobile network, the Cell Broadcast Service (CBS) allows low bit-rate data to be transferred to all users via a shared broadcasting channel of a cell, which is categorized as a message service.
At present, demand for mobile communications has gone beyond telephone and message services. Along with the rapid development of the Internet, there emerge a great deal of multimedia services, some applications of which require that multiple users be able to receive the same data at the same time, e.g. video-on-demand (VOD), telecast, video conference, network-based education, and interactive video games. Compared with conventional data, these multimedia services are featured with large data flow, long time duration, and high sensitivity to time delay. In prior art, IP multicast is only applicable to fixed IP networks rather than mobile networks, for mobile networks have special network architectures, functional entities, and wireless interfaces, which are all different from those of a fixed IP network.
In order to make efficient use of mobile networks resources, the WCDMA/GSM global standardization organization, 3GPP, has put forward MBMS, which is designed to provide point-to-multipoint services of transferring data from one source to multiple users in mobile networks so as to share network resources and improve the utility rate thereof, especially the utility rate of wireless interface resources. MBMS defined by 3GPP can implement not only multicast and broadcast of plain text and low-rate messages, but also multicast and broadcast of high-rate multimedia services, which is no doubt in the trend of future development of mobile data transmission.
In order to support MBMS, a new mobile network functional entity, Broadcast Multicast-Service Center (BM-SC), is added to mobile networks. BM-SC is the entrance of content providers and used for authorizing and initiating an MBMS bearer service as well as delivering MBMS transmissions according to the scheduled timetable. In addition, functional entities, such as user equipment (UE), Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access Network (UTRAN), Global System for Mobile communication (GSM) Enhanced Data rates for GSM Evolution (EDGE) Radio Access Network (GERAN), Serving General Packet Radio Service (GPRS) Support Node (SGSN), and Gateway GPRS Support Node (GGSN) are enhanced by absorbing relevant functions of MBMS.
Such network architecture is shown in FIG. 1, which is a schematic diagram illustrating a radio network architecture supporting multicast/broadcast services, wherein, BM-SC is connected with the GGSN via the interface Gmb or Gi, and one BM-SC may be connected with multiple GGSN; GGSN is connected with the SGSN via the interface Gn/Gp, and one GGSN may be connected with multiple SGSN; SGSN may be connected via the interface Iu with UTRAN, which is in turn connected with UE via the interface Uu; SGSN may also connected via the interface Iu/Gb with GERAN, which is in turn connected with UE via the interface Um.
MBMS includes the multicast mode and the broadcast mode, and the difference between the two modes lies in that in the multicast mode, relevant information only to be sent to the users who have subscribed to the information while in the broadcast mode, information to be sent to all users of the radio network. In the multicast mode, it is required that a user subscribe to an appropriate multicast group, the service be activated, and relevant billing information be generated. As there is difference between the multicast mode and the broadcast mode in service demand, the service procedures thereof are different.
There are two modes of MBMS data transmission between UTRAN and UE: the point-to-multipoint (PTM) mode and point-to-point (PTP) mode. In the PTM mode, the same data are sent via the MBMS PTM traffic channel (MTCH), and may be received by all UE that have joined in the multicast service or are interested in the broadcast service. In the PTP mode, data are sent via a dedicated traffic channel (DTCH), and can be received only by a corresponding UE.
The whole process for UE to receive a certain MBMS broadcast service is shown in FIG. 2a, which comprises the phases of Service Announcement, Session Start, MBMS Notification, Data Transfer, and Session Stop.
Here, in the Service Announcement phase, the BM-SC informs the UEs about forthcoming user services.
In the Session Start phase, the BM-SC is ready to send data and triggers the bearer resource establishment in the core network (CN) and the UTRAN.
In the MBMS Notification phase, the UEs are informed about forthcoming MBMS broadcast session.
In the Data Transfer phase, the BM-SC transfers MBMS data to the UEs through the bearer resources established in the Session Start phase.
In the Session Stop phase, the bearer resources established in the Session Start phase is released.
In a broadcast service, each MBMS service node stores the MBMS bearer context, and the MBMS bearer context is activated in the Session Start phase and deactivated in the Session Stop phase.
The whole process for UE to receive a certain MBMS multicast service is shown in FIG. 2b, which comprises the phases of Subscription, Service Announcement, Joining, Session Start, MBMS Notification, Data Transfer, Session Stop, and Leaving.
Here, in the Subscription phase, the user subscribes to the desired MBMS services in advance.
In the Service Announcement phase, the BM-SC informs the user about forthcoming user services.
The Joining phase is the MBMS multicast service activation phase. In the Joining phase, the UE indicates to the network that it wants to become a member of the current multicast group and receives the multicast data of the specific MBMS bearer service. An MBMS UE context containing the information of UE joining the multicast group is created in both the network and the UE during the Joining phase.
In the Session Start phase, the BM-SC is ready to send data and triggers the bearer resource establishment in the CN and the UTRAN.
In the MBMS Notification phase, the UEs are informed about forthcoming MBMS multicast session.
In the Data Transfer phase, the BM-SC transfers MBMS data to the UEs through the bearer resources established in the Session Start phase.
In the Session Stop phase, the bearer resources established in the Session Start phase is released.
The Leaving is the process by which a subscriber leaves a multicast group, i.e. the user no longer wants to receive multicast data. The corresponding MBMS UE context is deleted during the Leaving phase.
In the procedures of MBMS, the cell information that the network side sends to the UEs does not remain unchanged but changes along with the changes of service, e.g. such cell information as the radio bearer (RB) information that the network side sends to the UEs and the services currently provided by the network side may change. The procedure by which the network side sends the UEs cell information at present is hereinafter described by taking the procedure of the network side sending the UEs the RB information as an example.
When the access network establishes radio bearer resources, the BSC/RNC at the network side will notify the UE of the RB information of the MBMS service. The RB information includes radio bearer configuration information (e.g. Packet Data Convergence Protocol (PDCP)) and radio bearer mapping information (e.g. Radio Link Control (RLC)), as well as configuration information of the transfer channel and physical channel.
If there is change in the RB information of the MBMS that is to be or being transferred in the cell, the network side will instruct the UEs to receive the changed RB information. The information instruction that notifies the UEs of the change in RB of the local cell is transferred in the MBMS MODIFIED SERVICES INFORMATION (MMSD) message. According to the action instructed by this message, the UEs further receive the RB information. Both the MMSI message and the RB information are transferred via the MBMS Control CHannel (MCCH).
The RB information that the network side sends via the MCCH to the UEs, however, comprises only the RB of the local cell.
As specified in the protocol, the procedure at present for the network side to notify the UEs of the RB parameters of MBMS service is carried out in the following two situations:
1. A UE has joined an MBMS service that the local cell has not yet provided:
In this case, no matter which state the UE is in (either Idle state or Radio Resource Control (RRC) connected state), it will monitor the MBMS notification Indicator CHannel (MICH);
The network side can obtain the RB information of adjacent cells via SGSN, and may adjust the RB information of the local cell according to the need of service.
When the RB information bearing the service in the local cell changes, the network side indicates the change of the service in MICH. When learning from MICH that the service to its concern has changed, the UE will further demodulate the RB information message carried in the notice of RB information change of the service to acquiring the RB information of the changed service, wherein the notice of RB information change of the service may be obtained from the MMSI message in MCCH.
2. The UE is receiving the MBMS service:
In this case, no matter which state the UE is in, it will receive periodically the signal of the MCCH;
The BSC/RNC can obtain the RB information of adjacent cells via SGSN. The network side may adjust the RB information of the local cell according to the need of service.
When the RB information bearing the service of the local cell changes, the network side indicates the change of the service in the MMSI message in MCCH. While receiving the MBMS service, if obtaining the notice of RB information change of the service from the MMSI message in MCCH, the UE will further demodulate the RB information message borne by the corresponding MCCH so as to acquire the RB information after the change of the service.
It can be seen from the foregoing procedures in the prior art that, at present, only when the RB information of the local cell changes will the network side notify the UEs of the change of the RB information via MICH or the MMSI message in MCCH, i.e. in the prior art, only the change of the RB information of the local cell will trigger the UEs demodulating the RB information.
As the specific situation in an adjacent cell is likely to be different, and the types of services provided in a cell may be different as well, the RB information of adjacent cells is probably different. According to the existing protocol, however, the change in RB information of the service in an adjacent cell is not reflected in the MMSI message. In another word, if the RB information of an MBMS service in the local cell does not change but the RB information in an adjacent cell changes, the UEs in the local cell have no way of being notified of the change of the RB information in the adjacent cell.
When a UE is receiving an MBMS service and has moved to the border of two cells, it is possible for the UE to perform the selective/soft merging function for the service at the border of two adjacent cells. The selective merging is to compare the information of the same service received from two adjacent cells at the RLC layer and select the data with better quality. The soft merging is the same as the soft merging function in the existing WCDMA system, which is not to be described in detail herein. In this scenario, therefore, if the UE has not updated the saved RB information along with the updating of the RB information in the adjacent cell, leading to an error in the RB information, the UE will not be able to receive the information of the same service from the adjacent cell and accordingly not be able to perform the merging function.
Likewise, as to other types of cell information, it is only possible in the prior art that the UEs are notified of the change of cell information in the local cell via MICH or MCCH. If the information of adjacent cells changes but the information of the local cell does not change, the UEs will not be notified. As a result, when a UE moves to the border of two adjacent cells, it is likely that the UE is not be able to perform the corresponding functions due to the error in the cell information.